1. Field of the Invention
The present invention relates to the field of resource understanding tools and more particularly to distributed resource understanding.
2. Description of the Related Art
Software development has advanced from the primitive form of the mid-twentieth century to today. Early software development involved few assistive tools and often took the form of punch card processing. Later software development permitted the electronic keying of source code that could be processed by a separate compiler and linker to produce an executable computer program. Modern software development environments, however, provide a wide array of assistive tools, often grouped together in an integrated development environment (IDE). Advanced forms of the IDE further include resource understanding tools.
Resource understanding tools refer to assistive tools that facilitate the development and deployment of program code or other application logic utilizing ancillary resources such as text strings, bitmapped graphics, fonts, data stores and the like. Generally, a resource understanding tool can provide assistance to a developer in forming or modifying program code. Exemplary uses include content assist tools that automatically present content such as available operands to complete a source code expression, a list of bitmapped resources available for use in a user interface, and a list of data stores able to be accessed through a source code expression, to name only a few.
Resource understanding tools provide the backbone for integrated development environments. Such tools enhance code understanding and empower software developers to perform many sophisticated programming operations that can dramatically improve productivity. Abstract Syntax Tree (AST) builders and the features that make use of the produced constructs are not new and have been utilized for many years by developers. When a developer targets the local platform, AST builders can be invaluable. Notwithstanding, there are limitations that existing implementations impose on other software development niches.
For instance, there are cases where a programmer must write, analyze, test and debug software for specific platforms other than programmer's workstation. In many cases, a programmer does not have direct access to the target platforms, such as the case when the target platform is a mainframe or midrange computer, or where the target platform is a special device such as a mobile phone, a grid computing system, or where the target is a multi-platform system. In these cases, resource understanding tools can be restricted in scope.
To serve programmers well, the complete set of resources required by a project must be accessible by the resource understanding tool. For example, in order to produce a proper AST for a distributed application project, a parser must access not only the resources that make up the project, but also the include files and macros defined on all remote, host platforms. Although users may still be able to work with the resources of a project locally while gathering some understanding of those resources through local tooling, the local tooling would be unable to access the included files and macros in the environment of the different host platforms. Accordingly, conventional resource understanding tools running in the local environment cannot produce an accurate or complete understanding of the resources of a distributed application project.
Given that the accessibility of the complete set of resources and the target environment is required to produce a complete and accurate understanding of a software development project, a natural solution would include running the resource understanding tool on the remote host rather than on the local client. Notwithstanding, since the programmer remains bound to the local workstation, a mechanism to connect the local IDE to the remote resource understanding tool remains. Consequently, such a solution can become far more complicated than the local scenario because now the tooling is spread out such that the user interface (UI), program visualization, and editing occurs locally while program understanding occurs on the host.
Not only would this proposed solution perform slowly due to the additional remote communications link but also, because the programmer edits source code locally, one skilled in the art would recognize that the remote resource understanding tool would have an even less accurate understanding of the resources than the incomplete localized solution version. Furthermore, the remote resource understanding tool would be unavailable for users wishing to do development offline.